1.1 Introduction
This invention relates to a method for improving security in a computer system. More specifically, this invention concerns a method for implementing trusted commands through both trusted and untrusted code.
1.2 Background
The proliferation of computers has resulted in the need for reliable computer security systems. The need to protect certain information is great in areas dealing with national security, for example. Security measures are required in other fields, including areas which utilize financial, medical, and personal information. Many computerized information systems therefore include internal security measures which provide the users with different levels of access to the computerized information, and which attempt to provide at least a degree of protection of the information from undesirable access.
1.3 Security Criteria: Reference Validation Systems
In response to the need for secure computer systems, the Department of Defense has issued a publication titled Department of Defense Trusted Computer System Evaluation Criteria (reference No. DOD 5200.28-STD). This publication is sometimes referred to as the xe2x80x9cOrange Book,xe2x80x9d and is available from the Department of Defense. The Orange Book describes system security objectives and evaluation criteria for secure computer systems.
A xe2x80x9csecurexe2x80x9d computer system generally includes some type of xe2x80x9creference validationxe2x80x9d system. These reference validation systems (known as reference monitors) are responsible for enforcing the security rules (security policy) for a given computer system.
Reference monitors mediate all access to xe2x80x9cobjectsxe2x80x9d by xe2x80x9csubjectsxe2x80x9d. Objects are passive entities that contain or receive information. Access to an object implies access to the information that it contains. Subjects are active entities, generally in the form of a person, process or device that cause information to flow among objects or change the system state. A subject may ordinarily reference its own, subject-internal information without the involvement of the reference monitor. Reference monitors controlling such access to objects by subjects are known in the art, and may utilize a security kernel approach.
Proper implementation of a reference monitor calls for adherence to three principles:
(1) completeness, in that all access by subjects to objects or other subjects must involve the monitor;
(2) isolation, in that the monitor must be protected from tampering; and
(3) verifiability, in that correspondence must be shown between the security policy and the actual implementation of the monitor.
As discussed, every reference to information or change of authorization should go through the reference monitor. Thus, all commands issued by a user or other subject are monitored by the reference monitor. This approach is particularly useful in multiuser computer environments.
The totality of the protection mechanisms within a computer systemxe2x80x94including hardware, software, and firmware, the combination of which is responsible for enforcing a security policyxe2x80x94is commonly known as a xe2x80x9ctrusted computing basexe2x80x9d (TCB). If the trusted software is designed to be as simple as possible, for the sake of verifying the reference monitor, then the trusted software is known as a xe2x80x9csecurity kernelxe2x80x9d.
Generally, TCBs attempt to meet the control objectives set out in the Orange Book. Compliance with these objectives inspires user confidence, and increases the overall desirability of a computer system. These objectives deal with:
(1) security policy;
(2) accountability; and
(3) assurance.
The security policy objective entails enforcement by the TCB of the desired security rules. These security rules are designed to limit the access to and dissemination of information in a precisely defined manner.
Security policies may include provisions for the enforcement of both mandatory and discretionary access control rules. Mandatory access control rules control access based directly on comparisons of the user""s security level and the sensitivity level of the information being sought. Discretionary access rules control and limit access to identified individuals who have been determined to have a need-to-know.
These access control rules call for associating with each user identification code a statement indicating the user""s access rights. This statement often includes information representing the user""s security level (for mandatory control purposes), and membership in groups (for discretionary control purposes).
The accountability objective calls for providing each user with an individual user identification code (often called a xe2x80x9cuser namexe2x80x9d) and for the TCB to be able to recognize the code and ensure that it is being used by its proper user. This may be done by checking the user""s password. This ensuring the user""s identity is known as xe2x80x9cauthentication.xe2x80x9d
In addition, the accountability requirement calls for the existence of auditing capabilities. Such capabilities allow for the auditing of actions which can cause access to, generation of, or release of classified or sensitive information.
1.4 Assurance Objectives and xe2x80x9cTrustedxe2x80x9d Systems
The assurance objective is especially important in the present context. That objective is concerned with taking steps to ensure that the security policy is correctly implemented and that the TCB accurately mediates and enforces the intent of that policy. Steps may be taken to insure that each portion of the TCB is assured. To accomplish this objective, two types of assurance are needed.
The first type of assurance is life-cycle assurance. This type of assurance refers to steps taken to ensure that the computer system is designed, developed, and maintained using formalized and rigorous control standards.
The second type of assurance is operational assurance. Operational assurance deals with the features and system architecture used to ensure that the security policy is uncircumventably enforced during system operation. All of the software (sometimes referred to informally in the art as xe2x80x9ccodexe2x80x9d) in the TCB is generally analyzed to determine the assurance level of the system.
As the amount of code in the TCB increases, it becomes more difficult to ensure that the TCB accurately enforces the security policy. Because of this, it is desirable to minimize the amount of trusted code, and thus the complexity of the TCB.
A TCB is usually operated in a conjunction with a substantial amount of software, such as text editors and other applications, operating within the security policy of the TCB. Generally, this untrusted software asks the TCB for access to objects when the user or the untrusted software requires them. Thus, the majority of the user""s requests to the TCB, and the majority of the information that a user obtains from the TCB, are handled through the agency of untrusted software.
This untrusted software, however, is by nature in danger of compromise and vulnerable to bugs. For some types of requests and displays, malicious or malfunctioning untrusted software could compromise the enforcement of the security policy. Generally, TCBs cannot distinguish between requests faithfully made by the untrusted software on command from a user and either (1) requests made by the untrusted software at its own initiative (2) or requests that misrepresent the user""s actual command. For example, if commands issued by an authorized user to change certain users""security levels were made through the agency of untrusted software, it would be possible for malicious or malfunctioning untrusted software to inappropriately raise the security level of a user. Such inappropriate raising of a security level could result in the disclosure of sensitive information.
Furthermore, TCBs generally cannot ensure that displays made by untrusted software are faithful. This poses problems in that if displays of audit records were made through the use of untrusted software it would be possible for malicious untrusted software to misrepresent these audit records to hide suspicious activities.
To overcome these problems, prior-art systems have developed a concept known as a xe2x80x9ctrusted path.xe2x80x9d A trusted path is a mechanism by which the user can communicate directly with the TCB. A trusted path may only be activated by the user or the TCB and cannot be imitated by untrusted code. Such a trusted path is a positive TCB-to-user connection that bypasses all untrusted software. The Orange Book requires a trusted path for all systems that are given a security rank of B2 or above.
A xe2x80x9ctrusted commandxe2x80x9d (also known as a trusted-path command) is a command which requires a trusted path between the user and the TCB for execution. The specific security policy of a computer system will determine which commands are defined as trusted commands. For example, commands relating to changes of the security levels of users would be trusted commands.
1.5 Parsers as Increasers of System Complexity
Partly because of perceived performance problems, prior-art computer systems often included code to implement certain functions in the TCB. One such function comprises a portion of code known as the xe2x80x9cparser.xe2x80x9d
The parser performs the basic interpretation of user commands by translating a human-readable representation of a user command (e.g., a command typed by a user at a keyboard) into a machine-readable representation known as the binary representation, or the parsed command. A user command may consist of a group of words, typed by the user, specifying some action to be taken. The user command may also specify one or more variations or options of that action.
For the convenience of the user, most parsers allow these option words to be typed in any order without changing the meaning of the user command. Also, most parsers allow the user to type the words in either full or abbreviated form. In some instances, several possible abbreviations exist. Further, in most parsers, the user may vary the spacing between the words without changing the meaning of the command. Some parsers also check user commands for proper syntax, and report errors to the user prior to execution of the command. Other parsers prompt the user for missing information, avoiding the need to completely retype an incomplete command.
Thus, several different inputted human-readable representations may be associated with each unique parsed command. It is the job of the parser to translate accurately these inputted representations of user commands (which may vary with each user) into specific parsed command representations. Due to the complex nature of parsing, large amounts of computer code are generally associated with this activity.
Prior-art trusted software systems have included the parser for trusted commands, and thus the associated code, within the TCB. In these systems every trusted command was parsed and executed exclusively by trusted code. The inclusion of the parsing code in the TCB was regarded as necessary for proper system operation.
As discussed above, however, the ease and degree of assuring a system is roughly inversely proportional to the complexity of the system""s TCB. Thus, the inclusion of the parser in the TCB results in more complex assurance analysis and a corresponding decrease in system confidence. Prior art devices (since they needed to be small and simple to support assurance) have thereby inherently constrained the user-friendliness of computer systems.
The present invention provides a number of advantages over the prior art. By reducing the complexity of the TCB, the amount of trusted code that must be verified or assured is reduced. In addition, the general usability of the system is increased, because the improved method of processing trusted commands allows for the implementation of added computing functions at little or no additional cost in TCB assurance.
The present invention includes an improved method for the execution of trusted commands. In this improved method, the required steps for processing a trusted command are split between trusted and untrusted code. In this manner the amount of trusted code in the TCB may be significantly reduced.
As discussed above, the parsing of a command can be comparatively difficult, and often requires large amounts of complex code. However, it is relatively simple to translate the parsed representation of a command into a standard human-readable representation for display to the user. This is in part because a single, standard human-readable display representation may be associated with each parsed representation. The present invention takes advantage of this fact by parsing the trusted commands in untrusted code prior to execution in the TCB.
In general, the present invention includes a computer system which includes a TCB operating as a reference monitor. Included in the TCB is the security-relevant code necessary for the actual execution of a trusted command.
Associated with the TCB are one or more untrusted subjects (e.g. processes). Each such subject has particular access rights, which may include a security level. These untrusted subjects communicate only with the involvement of the TCB. The TCB allows communication only as permitted by the system""s security policy. Each untrusted subject is substantially independent.
In each of these untrusted subjects, untrusted software is generally run. This untrusted software may include an untrusted operating system (UOS), and generally includes applications such as text editors. In the present invention, the untrusted code includes the non-security relevant functions necessary for the execution of a trusted command.
Attached to the computer system are several user terminals. These user terminals allow the user to exchange information with the computer system. All terminal activity is seen first by the TCB. A secure-attention key is dedicated for use on each terminal attached to the computer system. The TCB is designed to recognize and trap this key signal. Activation of this key by the user establishes a trusted path between the user terminal and the TCB. Alternate methods for establishing a trusted path may be utilized.
The TCB is generally provided with a limited number of xe2x80x9cdirectxe2x80x9d user commands (direct commands). Because of this, the majority of the user""s activities will take place in the untrusted operating system.
While operating in the UOS, the user may attempt to execute a trusted command. When one of these commands is issued by the user, the untrusted code in the UOS checks the syntax of the command and may prompt for missing parameters; then the untrusted parser converts the command into a parsed representation that will be referred to here for convenience as the xe2x80x9cbinary representation.xe2x80x9d In some instances, command procedures and application-issued trusted commands will also be parsed and translated into a binary representation.
This binary representation is then passed from the UOS to the TCB. The TCB initially associates the binary representation with a physical terminal, and copies the binary representation into a memory buffer assigned to that terminal.
Once, this has been completed, the untrusted code in the UOS may prompt the user to activate the secure-attention key. If this key is activated, a trusted path will be established between the user terminal and the TCB. Alternate methods may be employed to initiate this trusted path. A randomly generated process ID, which may be generated at login, may be utilized to prevent untrusted code from simulating a trusted path.
Subsequent activity by the TCB depends on the type of command that is represented by the binary representation. If the command is one that will not modify any information, i.e., a request to view information, the TCB verifies that the user has the necessary access rights, and attempts to execute the binary representation. A human-readable standard representation of the binary command received by the TCB is displayed along with the information.
In most instances, if the command requested by the user requests modification of information, the TCB displays for confirmation a standard human-readable form of the command, along with an indication of what the result of command execution will be. The user is then requested to confirm (by typing a response via the trusted path) that the displayed command was received correctly and should be executed.
This confirmation allows the user to ensure that untrusted code has not performed an unauthorized modification of the user""s original command. Also, confirmation allows for the detection by the user of any errors that may have occurred during the parsing process. In situations where the binary representation represents a command procedure or an application-issued trusted command, the confirmation ensures that the command proposed by the untrusted software is acceptable to the user.
If the command is confirmed by the user, the TCB checks to ensure that the user has the necessary access rights to execute the command and, if so, attempts to execute the command.
A distinct advantage of the present invention arises from the fact that the execution of a trusted command is split between trusted code and untrusted code. The actual parsing of the command occurs in untrusted code. The trusted code included in the TCB checks the parsed command for correctness and displays it to the user in human readable form. This checking and display of a parsed command requires substantially less code than is required to parse a command.
Thus, since the command parser is included in the untrusted code, the amount of trusted code in the TCB is minimized. This lowers the difficulty of trusted system assurance, and increases the amount of confidence that may be placed in a system.
It is a further advantage of this invention that the user interface is separate from the underlying functions performed by the TCB. This allows for implementation of alternate UOS-to-user interfaces without major modification of the TCB. Further, the amount of time and effort to develop such a command interface is reduced. A still further advantage is that more useability features may be provided without substantially increasing the complexity of the TCB. Examples of such useability features are command-line editing and recall.